Enforcing payment schedules

ABSTRACT

A payment schedule enforcement system and method cause various actions to be taken in response to nonpayment by the debtor. Such actions include remotely activating an alert message, disabling a vehicle or other product, or the like. Upon occurrence of a specified event, a message is sent to a remotely located device, such as one installed in a vehicle or other product. The remotely located device is configured so that it can disable the vehicle (for example by disabling the starter circuitry) upon receipt of the message from the operations center.

CROSS-REFERENCE TO RELATED APPLICATION

This invention is related to U.S. patent application Ser. No. 10/856,968for “Encoding Data in a Password”, filed May 28, 2004, the disclosure ofwhich is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to enforcement of payment schedules byremote disablement of a device in response to a missed payment or otherevent.

2. Description of the Related Art

Lenders have various mechanisms for enforcing payment of debtobligations, particularly those obligations that arise from the sale ofgoods or property on credit. For example, mortgagees can foreclose onreal property if a mortgagor defaults. Vehicle finance companies canrepossess a vehicle in the event the purchaser fails to make timelypayment.

In some cases, payment schedule enforcement mechanisms based onforeclosure and/or repossession are expensive and cumbersome toimplement. Accordingly, lenders often refuse to extend credit when thelikelihood of default exceeds some amount, because of the expense orimpracticality of repossessing or otherwise enforcing paymentobligations. In particular, potential buyers with bad credit history maybe denied credit when attempting to purchase a vehicle or other itembecause of the relatively high likelihood of default. In addition,payments on less expensive items such as appliances, computers, and thelike are often difficult to enforce because repossession is far tooexpensive in relation to the value of the item itself, and because theitem loses much of its value once it is used.

Payment enforcement systems exist whereby a vehicle (or other purchasedproperty) is equipped with a device capable of disabling the vehicle inthe event of non-payment. Whenever the purchaser makes a timely payment,he or she is given a password to enter on a keypad installed in thevehicle. Entry of the password enables the vehicle for some limitedperiod of time (usually until the next payment due date, plus some graceperiod). Failure to enter the password causes the vehicle to bedisabled, for example by interrupting the starter circuitry. Usually,the purchaser is given some warning of impending disablement, and mayalso be provided with a limited number of emergency starts whereby thevehicle can be used a few times even if a code has not been entered. Insome variations, the password is transmitted wirelessly to the vehicleso that the purchaser need not enter it manually.

Such systems, available for example from PassTime USA of Littleton,Colo., are effective in reducing the incidence of default. However,significant human intervention (and thereby expense) is involved, whichcan reduce the efficiency of such mechanisms. In addition, such systemsare decentralized, with timer logic and password authentication at thevehicles themselves rather than centrally located. In addition, there isoften some burden and stigma associated with having a paymentdisablement system installed in a vehicle, which limits the feasibleapplication of such devices. In addition, such devices are usuallyconfigured as “fail-safe to disable”, meaning that if no code is enteredor no other communication is received, the vehicle will be disabled.

What is needed is an improved system and method for enforcing paymentschedules in a centralized, flexible manner. What is further needed is apayment enforcement mechanism that is practical to install in manydifferent types of products and devices. What is further needed is apayment enforcement mechanism that is capable of responding to varioustypes of events. What is further needed is a payment enforcementmechanism that reduces the amount of effort and burden imposed on theowner (end purchaser) and minimizes or eliminates the need for codeentry.

SUMMARY OF THE INVENTION

According to the techniques of the present invention, an improvedpayment schedule enforcement system and method are provided. Varioustypes of events can be configured via software running at an operationscenter. Upon occurrence of a specified event, a message is sent to aremotely located device, such as one installed in a vehicle or otherproduct. The remotely located device is configured so that it candisable the vehicle (for example by disabling the starter circuitry)upon receipt of the message from the operations center. Inimplementations involving products other than vehicles, other mechanismsfor disabling the product (such as cutting off power to the product) canbe used. The remotely located device can be instructed to allow acertain number of emergency uses, or to accept an override password thatre-enables use of the vehicle.

For example, the system of the present invention can be configured witha payment schedule. If a buyer of a vehicle fails to make payment by acertain date, the system of the present invention automatically sendsmessages to a device installed in the vehicle to take appropriate actionsuch as output a series of warning alerts and/or disable the startermechanism for the vehicle.

In one embodiment, the remotely located device is implemented as part ofexisting communicatively enabled components of the vehicle (such as anavigation system and/or Global Positioning System (GPS)). In anotherembodiment, it is implemented as an add-on device that can be installedin any vehicle. In another embodiment, the driver of the vehicle cancommunicate with the remotely located device via voice communication. Inaddition to triggering disablement, the operations center can sendmessages that cause the device to alert the customer as to certainconditions (such as a warning of impending disablement, or availabilityof product updates, or receipt of payment, or the like). Messages fromthe operations center can be sent in accordance with a predefinedschedule or in response to manually entered instructions from a systemoperator. In one embodiment, the operations center can also receivemessages from remotely located devices, including for exampleacknowledgments, marketing data, position information, usageinformation, or the like.

In one embodiment, the operations center can also send messages toexternal agents such as repossession agents, roadside assistanceproviders, or the like. Depending on the circumstances, these externalagents can be provided with additional information (such as, forexample, GPS data specifying the location of the vehicle). In such amanner, the present invention provides a technique for initiatingthird-party response to the triggering event where appropriate.

The present invention thus provides a system and method for enforcingpayment schedules that avoids the limitations of prior art systems.Improved flexibility and ease-of-use are provided by the use of anoperations center that transmits messages instructing remotelycontrolled devices to disable products or to perform other functions.The present invention thus enables payment enforcement with lessreliance on decentralized components and without requiring repeatedtransmission of codes (or manual entry of codes) to keep a vehicle fromshutting down.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an overall architecture for an embodiment of theinvention.

FIG. 2 is a flow diagram depicting operation of the invention accordingto one embodiment.

FIG. 3 depicts an example of a user interface screen for setting upcustomer information and payment schedule according to one embodiment.

FIG. 4 depicts an example of a user interface screen for viewing GPSinformation, customer information, and payment history, according to oneembodiment.

FIG. 5 depicts an example of a user interface screen for specifyingwarning periods, shutdown periods, payment information, and the like,according to one embodiment.

FIG. 6 depicts an example of a user interface screen for displaying alocation of a vehicle, according to one embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

According to one embodiment, the present invention is implemented as asoftware application running at an operations center. The softwareapplication detects events and generates messages in response to theevents. These messages are received by remotely located devicesinstalled in vehicles or other products. Upon receiving a message, theremotely located device takes appropriate action, such as issuing analert, disabling the vehicle, or the like.

For purposes of the following description, the invention is set forth interms of a system for disabling vehicles in the event of nonpayment bythe owner (purchaser) of the vehicle. One skilled in the art willrecognize, however, that the techniques of the present invention can beused in many other contexts as well. For example, the invention can beused to disable any product remotely in response to certain triggerevents. In addition, the invention can be used to generate messages andalerts, either to the purchaser or to a third party, in response toevents. Accordingly, the following description is intended to beexemplary of one particular embodiment, and is not intended to limit thescope of the invention.

Referring now to FIG. 1, there is shown a block diagram depicting anoverall architecture for an embodiment of the invention. Software 102running at operations center 101 performs much of the functionality ofthe present invention. In one embodiment, operations center 101 issituated at some central location and is operated by or on behalf of alender, seller, or loan service company. Appropriate communicationsinfrastructure, such as Internet, wireless, and/or telecommunicationsconnectivity is provided, so as to allow operations center 101 tocommunicate with other elements of the overall system.

System administrator 104 interacts with software 102 via user interface103, which allows system administrator 104 to specify options,schedules, alert conditions, and the like, and also allows systemadministrator 104 to view reports, monitor system operations, and thelike. System administrator 104 may be located at or near operationscenter 101, or may be remotely located, in which case interactions withsoftware 102 may take place over a computer network such as theInternet, virtual private network, or the like, according to techniquesthat are well known to those of skill in the art.

Payment schedule 105 for a particular debtor is stored, for example, ina database or other data store at operations center 101 or at some otherlocation. Software 102 enforces payment schedule 105 by sendingappropriate messages 107A, 107B to vehicle 109 and/or to external agent108, respectively. Software 102 is communicatively coupled withaccounting systems (not shown) or other sources of data that informsoftware 102 when a payment is late or when other relevant events takeplace that require messages 107A, 107B to be sent.

In one embodiment, software 102 invokes event management middleware 106to send messages 107A to device 111 at vehicle 109. In one embodiment,middleware 106 can also be used for sending messages 107B to externalagent 108, although in other embodiments messages 107B are sent directlyby software 102. Middleware 106 provides an interface by which software102 can communicate with many different types of devices, systems,computers, vehicles, nodes, and the like, via a variety of protocols.Essentially, middleware 106 acts a protocol translation module betweensoftware 102 and whatever entities software 102 communicates with. Forexample, for certain devices 111, Internet Protocol (IP) may be anappropriate communication medium, whereas cell or pager messages may bethe appropriate mechanism for other devices 111. Examples of othercommunication protocols that can be used include GPRS, SMS Edge, Java,SQL and the like. In one embodiment, the present invention isimplemented using mobile device middleware available from Intellimaticsof Coppell, Tex. Standard ODBC protocols can be used to communicate withIntellimatics databases (via SQL).

In addition to sending messages 107A and/or 107B, in one embodiment,middleware 106 can also receive messages. For example, middleware 106may receive acknowledgement messages from device 111 and/or agent 108 toconfirm receipt of messages 107A and/or 107B. Also, vehicle 109 may haveGPS tracking capability, in which case GPS data can be sent tooperations center 101 via middleware 106 when it is deemed appropriateor useful to do so. Other information that may be usefully transmittedto middleware 106 includes: mileage (for example to enforce mileagelimits on rented or leased vehicles, or to determine whetherpreventative maintenance schedules are being followed).

Event management middleware 106 sends messages 107A to remotely locateddevice 111 installed in vehicle 109. Such messages 107A instruct device111 to perform various operations, such as disabling vehicle startercircuitry 112 in order to prevent operation of vehicle 109, outputtingalerts or other information to owner 110 via output mechanism 113, orthe like. Output mechanism 113 may be a speaker for issuing beeps andspoken information, or it may be a display screen for showing visualalerts, or some combination thereof. In one embodiment, output mechanism113 is a standalone output device connected to or part of device 111; inanother embodiment, output mechanism 113 can be implemented as part ofan existing component of vehicle 109 such as a GPS navigation system,onboard trip computer, or other component. In this manner, thetechniques of the present invention can be implemented in a manner thatis well integrated with existing input and output mechanisms alreadypresent in vehicle 109.

In one embodiment, software 102 also sends messages 107B to one or moreexternal agents 108 when appropriate, either via middleware 106 ordirectly or by some other means. For example, certain events may cause amessage 107B to be sent to a repossession agent or company, so thatvehicle 109 can be repossessed. Alternatively, certain events maywarrant notifying a credit card company, lender, or even a roadsideassistance provider. In one embodiment, middleware 106 can query device111 for GPS information regarding vehicle 109, and cause GPS data to besent to agent 108 so that agent 108 can quickly locate vehicle 109.

In one embodiment, software 102 can also receive messages 107C fromtechnology trigger 121. Technology trigger 121 can be any source ofinformation that is relevant to the payment schedule enforcementmechanism of the present invention. For example, technology trigger 121may be a data stream providing information from a payment system, sothat upon receipt of messages 107C from technology trigger 121, softwarecauses payment schedule 105 and/or other information to be updated.

As indicated above, the system of the present invention can be used withproducts other than vehicles as well, in which case device 111 might belocated in or attached to whatever product is subject to being remotelydisabled according to the methods provided herein. In one embodiment,device 111 is communicatively coupled to vehicle starter circuitry 112;in other embodiments, device 111 is configured and situated so that itis capable of disabling the subject product when it receives a messageinstructing it to do so. For example, device 111 can be configured to beable to shut off a power source (such as 110-volt AC) to an appliance orother product.

In one embodiment, device 111 receives communications from middleware106 via the same physical medium as is used to power the product (suchas AC power lines). Such an arrangement prevents owner 110 (or someother individual) from disabling communications with middleware 106without also cutting off power to the product. Such an embodiment may beeffective for payment enforcement on appliances that run on AC power.

Device 111 can include additional components to enhance functionality.In one embodiment, device 111 includes a WiFi repeater to enablecommunication with vehicle 109 or other products. The repeater iscapable of enabling and/or disabling certain actions within the vehiclesuch as fuel, ignition, or other components. Device 111 can communicatewith middleware 106 using any wireless or wired communication channel,including for example Internet, cellular, radio, GSM, pager, or thelike. In one embodiment, device 111 periodically polls middleware 106for messages; alternatively, device 111 is passive and only respondswhen middleware 106 sends messages. In one embodiment, device 111 has anIP address so that it can be directly addressed via the Internetprotocol.

Messages 107A and 107B may be encoded using any known encoding scheme orprotocol. In one embodiment, messages 107A and 107B arepassword-protected and/or encrypted to reduce the possibility ofinterception and/or tampering.

Referring now to FIG. 2, there is shown a flowchart depicting a methodof practicing the present invention according to one embodiment.Software 102 receives 201 payment schedule 105. In one embodiment,schedule 105 is provided via a computer-readable file such as a databasefile, which software 102 is able to read and interpret. In anotherembodiment, payment schedule 105 is transmitted to or otherwise conveyedto software 102. The operations by which software 102 receives 201payment schedule 105 may take place under the control of systemadministrator 104 via user interface 103. In addition, administrator 104can specify, via user interface 103, the characteristics of paymentschedule 105 and the various actions that should be taken in response tovarious conditions.

Software 102 detects 202 events relevant to payment schedule 105. In oneembodiment, software 202 is communicatively coupled with automatedsoftware modules (not show) that make software 102 aware of such events.In another embodiment, software 202 logs into Internet websites or othersources of information, providing appropriate authentication credentialswhen needed, to “scrape” or otherwise extract information relevant toevents. In yet another embodiment, system administrator 104 or anotherindividual performs manual data entry (for example via user interface103) to inform software 102 that an event has occurred.

For example, one event is the fact that owner 110 is late on a payment.The occurrence of such an event can be provided to software 102 in anyof several different ways. Software 102 may interact with accountingsoftware that outputs a list of accounts that are in default, so thatsoftware 102 can interpret such a list as indicating a set of nonpaymentevents. Alternatively, software 102 may log onto a secure website tocheck the status of various accounts and thereby determine that anonpayment event has taken place. Alternatively, system administrator104 may manually enter a nonpayment event via user interface 103.

In one embodiment, the lack of occurrence of a certain event can beinterpreted as the occurrence of a second event. For example, the systemof the present invention can be configured so that software 102 isinformed when a payment has occurred. In this case, failure to make apayment would not generate an event to be sent to software 102; rather,software 102 determines that since it has not received a payment eventwithin a specified time period, it should assume that a nonpayment eventhas taken place. In other words, software 102 can infer certain eventsbased on certain conditions.

Software 102 is configured to determine what types of messages areappropriate for different types of events. Based on such determinationsoftware 102 transmits 203 message 107A to remotely located device 111.In addition, if appropriate, software 102 transmits 204 message 107B toexternal agent 108. For example, software 102 may transmit a message107B to any or all of the following:

-   -   a repossession agent to initiate repossession proceedings;    -   a dealer or loan servicing agent to inform them of the        nonpayment event;    -   a roadside assistance provider in case of emergency;    -   a payment center and/or credit card processing operation to        arrange for payment; and/or    -   an interactive voice response (IVR) system to call owner 110 by        telephone to inform him/her of the event and action taken, and        to give owner 110 an opportunity to communicate with an        individual at operations center 101 and/or to enter payment        information directly.

As indicated above, messages 107A and 107B contain instructions as towhat type of action should be taken. In addition, messages 107A and 107Bcan contain additional information as may be useful: for example,message 107B to external agent 108 can contain GPS data for vehicle 109so as to assist external agent 108 in finding vehicle 109.

For example, software 102 may be configured to do the following:

-   -   send an alert to owner 110 upon detecting a nonpayment event;    -   send a second, more urgent alert after some number of days have        passed after a nonpayment event;    -   send a message 107A instructing device 111 to disable vehicle        starter circuitry 112 after some number of additional days have        passed; and    -   send a message 107B to a repossession agent or other external        agent 108 after some number of additional days have passed.

Any or all of these actions may take place automatically. Alternatively,software 102 can prompt administrator 104 to approve or deny the takingof a particular action before the corresponding message is sent. Forexample, before causing a vehicle's starter circuitry 112 to bedisabled, software 102 may prompt system administrator 104 to approvethe sending of such a message; thus, the message 107A is sent only ifthe administrator 104 approves of such action.

In one embodiment, software 102 (via middleware 106) sends such messages107A, 107B at the time that action is needed or desired. For example,software 102 tells device 111 to disable starter circuitry 112 now, andthe action is taken immediately. Additional messages are sent if andwhen additional action is to be taken. In another embodiment, software102 sends messages 107A, 107B that initiate a chain of actions accordingto a particular schedule. Thus, message 107A may instruct device 111 tosend an alert now, send a second alert after a certain number of days,and disable starter circuitry 112 after some additional days. In theabsence of further messages 107A from software 102, device 111 proceedsto take the specified actions according to the specified schedule. Thus,no further communications with operations center 101 are required inorder for device 111 to perform the chain of actions. Of course,software 102 can issue a later message 107A countermanding the originalmessage 107A (for example if payment is received after the first alertis output), so that the additional actions are not performed. In someembodiments, administrator 104 can configure whether actions should beperformed at device 111 in direct response to messages 107A or accordingto a schedule specified in messages 107A, or some combination thereof.

At any time, system administrator 104 can monitor payment status andother information, and can change or reconfigure actions taken under thedirection of software 102.

Messages 107A can specify any type of additional information and/orinstructions for device 111, including for example emergency overrideprocedures and parameters to allow owner 110 to operate vehicle 109 alimited number of times by entering an emergency code on a keypad. Inaddition, once payment has been received, a previous disablement can bereversed by sending a new message 107A indicating that vehicle operationshould be re-enabled.

Vehicle 109 can also be equipped with a mechanism for communicating withpersonnel at operations center 101 so as to inquire as to the reason foran action having been taken. Thus, for example, owner 110 can requestadditional time to make a payment, or explain that payment has alreadybeen made, or the like. Vehicle 109 can also be equipped with a keypad,if desired, for entry of an enablement code as is known in the priorart, although such keypad is not necessary to practice the presentinvention. Such keypad may be provided as an emergency alternative ifdirect communication between operations center 101 and device 111 fails.In one embodiment, a password entered via keypad encodes additionalinformation such as expiry date or the like, according to techniquesdescribed in related U.S. patent application Ser. No. 10/856,968 for“Encoding Data in a Password”, filed May 28, 2004, the disclosure ofwhich is incorporated herein by reference.

Vehicle 109 can also be equipped with a credit card reader (not shown)to take payments. Device 111 then sends a message to software 102, viamiddleware 106, to let software 102 know that payment has been received.Software 102 can be equipped to acknowledge that payment has been madeand can cause records to be updated accordingly.

Vehicle 109 can also be equipped with a user interface allowing owner110 to receive alerts and messages, and further allowing owner 110 tocommunicate with operations center 101. The user interface can beimplemented as part of device 111 or it can be communicatively coupledwith device 111. The user interface can include any of a screen,touch-screen, keyboard, trackball, mouse, voice communication system, orany combination thereof.

Accordingly, the present invention provides a mechanism by which paymentschedules can be enforced via remote disablement of vehicles 109 andother products. The present invention provides improved flexibility,automation, and reliability over prior art schemes. In addition, thepresent invention reduces the number of messages that need betransmitted, since messages need only be transmitted upon occurrence ofnonpayment events, as opposed to each time a payment is received: aslong as owner 110 makes timely payments, no messages need be sent. Inaddition, the present invention avoids false alarms that can occur whensystems rely on receipt of payment codes; thus, the invention reducesthe likelihood that an owner 110 making timely payments will beerroneously prevented from using his or her vehicle 109.

The system described herein is less obtrusive than existing systems thatrely on entry of codes to keep a vehicle from being disabled. The systemdescribed herein also reduces the stigma associated with paymentenforcement mechanisms, since it does not do anything unless a paymentdefault occurs. Accordingly, the system described herein is suitable foruse in connection with sales to good-credit customers as well aspoor-credit customers.

Many variations will be apparent to one skilled in the art. For example,the present invention can be implemented with slight variations toinhibit or disable use of a vehicle based on its location. An event canbe detection that the vehicle is being taken outside a specifiedpermitted geographic zone (such as a state, or municipal boundary). Aseries of warnings can be issued, followed by a message to disable thevehicle. Appropriate procedures are followed to ensure that the safetyof the driver is not compromised. Various consumer applications arepossible: for example, a parent could check on the location of his orher child based on the GPS reading on the vehicle. Upon determining thatthe child is in a safe location, the parent could remotely disable thevehicle so as to prevent the child from driving further.

In one embodiment, device 111 can cause certain features to be enabledor disabled based on various events. For example, if owner 110 makestimely payments, enhanced navigation functionality might be enabled onan onboard navigation system. If owner 110 fails to make timelypayments, an onboard entertainment unit can be disabled. Accordingly, insome embodiments, device 111 is communicatively coupled with otherfeatures and components of vehicle 109 such as GPS, navigation, orentertainment systems, so as to enable and/or disable such features inresponse to certain events.

User Interface

FIGS. 3-6 depict various examples of user interface screens for software102. In one embodiment, these screens are presented as part of userinterface 103 for use by system administrator 104 in configuring andoperating the system of the present invention. Of course, one skilled inthe art will recognize that these screens are merely exemplary and thatother layouts, components, and arrangements can be used.

FIG. 3 depicts an example of a user interface screen 300 for setting upcustomer information and payment schedule according to one embodiment.Screen 300 can be used when a new vehicle owner 110 is being added tothe system, for example in response to a new vehicle purchase.

Personal information about owner 110 can be entered in fields 301.Information about the vehicle can be entered in fields 302, 304, and305. Payment scheduling information can be entered in fields 303,including start date, number of payments, purchase price, paymentamount, payment schedule, account number, and grace days. In oneembodiment, the payment scheduling information entered in fields 303 isused to update payment schedule 105 and is then used by software 102 ingenerating events, as described above. Payment information for receivedpayments can be entered in fields 307. Right to cure information can beentered in fields 308. System administrator 104 clicks on button 309 tosubmit the entered information for entry in the appropriate databases,including for example payment schedule 105.

FIG. 4 depicts an example of a user interface screen 400 for viewing GPSinformation 403, customer information 405, and payment history 409,according to one embodiment. GPS information 403 is presented inlatitude and longitude format; clicking on View Map link 404 causes map600 to be displayed, as shown in FIG. 6. Clicking on Send Warning link401 causes software 102 to instruct middleware 106 to send a message107A to device 111, for example to alert owner 110 that payment has notyet been received. Clicking on Send Starter Disable link 402 causessoftware 102 to instruct middleware 106 to send a message 107A to device111 to disable vehicle 109. Such messages can be initiated from screen400 as a manual supplement to automatic generation of such messages thatis described above.

Payment history 409 includes a list of recently received payments. Inone embodiment, system administrator 104 can click on View links 410 inhistory 409 to see more information about a particular payment, and/orcan also click on Print links 411 to print receipts of payments.

Also shown in screen 400 are vehicle information 406, payment scheduleinformation 407, and email contact information 408.

FIG. 5 depicts an example of a user interface screen 500 for specifyingwarning periods, shutdown periods, payment information, and the like,according to one embodiment. Administrator 104 can enter a number ofdays until shutdown in field 501 or a shutdown date in field 502.Administrator 104 can enter a number of warning days in field 503 or awarning date in field 503A. Administrator 104 can also enter a number ofemergency days in field 504. Payment information can be entered infields 505, 506, and 507.

In the above description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofthe invention. It will be apparent, however, to one skilled in the artthat the invention can be practiced without these specific details. Inother instances, structures and devices are shown in block diagram formin order to avoid obscuring the invention.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the discussion, it isappreciated that throughout the description, discussions utilizing termssuch as “processing” or “computing” or “calculating” or “determining” or“displaying” or the like, refer to the action and processes of acomputer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system's memories or registers or other such informationstorage, transmission or display devices.

The present invention also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer, network of computers, or other apparatus.Various general-purpose systems may be used with programs in accordancewith the teachings herein, or it may prove convenient to construct amore specialized apparatus to perform the required method steps. Therequired structure for a variety of these systems appears from thedescription. In addition, the present invention is not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the invention as described herein.

As will be understood by those familiar with the art, the invention maybe embodied in other specific forms without departing from the spirit oressential characteristics thereof. For example, the particulararchitectures depicted above are merely exemplary of one implementationof the present invention. The functional elements and method stepsdescribed above are provided as illustrative examples of one techniquefor implementing the invention; one skilled in the art will recognizethat many other implementations are possible without departing from thepresent invention as recited in the claims. Likewise, the particularcapitalization or naming of the modules, protocols, features,attributes, or any other aspect is not mandatory or significant, and themechanisms that implement the invention or its features may havedifferent names or formats. In addition, the present invention may beimplemented as a method, process, user interface, computer programproduct, system, apparatus, or any combination thereof. Accordingly, thedisclosure of the present invention is intended to be illustrative, butnot limiting, of the scope of the invention, which is set forth in thefollowing claims.

1. A method for remotely disabling a product in response to an event,comprising: detecting a trigger event; and responsive to detection ofthe trigger event, transmitting a message to a device coupled to theproduct in order to disable the product.
 2. The method of claim 1,wherein disabling the product comprises preventing the product fromoperating.
 3. The method of claim 1, wherein disabling the productcomprises preventing a feature of the product from operating.
 4. Themethod of claim 1, wherein the trigger event comprises a paymentdeadline.
 5. The method of claim 1, wherein transmitting the message toa device comprises transmitting the message wirelessly.
 6. The method ofclaim 1, wherein transmitting the message to a device comprisestransmitting the message via the Internet.
 7. The method of claim 1,wherein transmitting the message to a device comprises transmitting themessage via a power line.
 8. The method of claim 1, wherein the productcomprises a vehicle.
 9. The method of claim 1, wherein the productcomprises one selected from the group consisting of: an appliance; acomputing device; a telecommunication device; a handheld computer; and apersonal digital assistant.
 10. The method of claim 1, wherein thetransmitted message causes the device to output a warning concerningdisablement.
 11. The method of claim 1, further comprising, responsiveto detection of the trigger event, transmitting a message to an externalagent.
 12. The method of claim 11, wherein the external agent comprisesat least one selected from the group consisting of: a repossessionagent; a credit issuer; a credit reporting agency; a lender; a roadsideassistance provider; and a seller of the product.
 13. The method ofclaim 1, further comprising receiving a message from the device.
 14. Themethod of claim 13, wherein the received message was entered by theoperator of the product associated with the device.
 15. The method ofclaim 1, further comprising receiving location information from thedevice.
 16. The method of claim 15, further comprising, responsive todetection of the trigger event, transmitting a message to an externalagent, the message comprising the received location information.
 17. Themethod of claim 1, wherein the message instructs the device to disablethe product at a specified time in the event no additional messages arereceived by the device.
 18. The method of claim 1, further comprising,outputting by the device an alert to indicate disablement of theproduct.
 19. The method of claim 18, wherein the alert comprises oneselected from the group consisting of a visual alert, an auditory alert,and a voice alert.
 20. The method of claim 1, wherein the device is ableto receive input from a user and provide output to a user.
 21. Themethod of claim 1, wherein the device is able to receive voice inputfrom a user and provide voice output to a user.
 22. The method of claim1, further comprising: responsive to detection of a second triggerevent, transmitting a message to a device coupled to the product inorder to re-enable the product.
 23. The method of claim 22, wherein thesecond trigger event represents user entry of payment information. 24.The method of claim 22, wherein the second trigger event represents userentry of payment information at a credit card reader.
 25. The method ofclaim 24, wherein the credit card reader is coupled to the product. 26.A method for remotely enabling a feature of a product in response to anevent, comprising: detecting a trigger event; and responsive todetection of the trigger event, transmitting a message to a devicecoupled to the product in order to enable the feature of the product.27. The method of claim 26, wherein the product comprises a vehicle, andthe feature of the product is associated with an onboard deviceinstalled in the vehicle.
 28. A method for enforcing a payment schedulefor a product, comprising: receiving a payment schedule; detecting atrigger event associated with the payment schedule; responsive todetection of the event, transmitting a message to a device coupled tothe product.
 29. The method of claim 28, wherein the trigger eventcomprises an impending payment deadline, and wherein the messageinstructs the device to output a warning.
 30. The method of claim 29,wherein the warning comprises an auditory warning.
 31. The method ofclaim 29, wherein the warning comprises a visual warning.
 32. The methodof claim 31, wherein the trigger event comprises a payment deadline, andwherein the message instructs the device to disable the product.
 33. Themethod of claim 31, wherein the trigger event comprises a paymentdeadline, and wherein the message instructs the device to output awarning and further to disable the product after a predefined period oftime if no additional message is received.
 34. A method for transmittinga message to a remotely located product, comprising: at an operationscenter, detecting a trigger event associated with the product;responsive to detection of the event, transmitting a message to a devicecoupled to the product, wherein the transmitted message causes thedevice to perform at least one selected from the group consisting of:disabling the product; and outputting a message concerning operation ofthe product.
 35. The method of claim 34, wherein the message comprisesat least one selected from the group consisting of: a warning ofpossible disablement; notification of available enhancement;notification of available upgrade; notification of available additionalproduct; and instructions regarding the use of the product.
 36. Themethod of claim 34, further comprising, responsive to detection of theevent, transmitting a message to an external agent concerning thetrigger event for the product.
 37. The method of claim 34, furthercomprising, responsive to detection of the event: detecting a locationof the product; and transmitting a message to an external agentconcerning the trigger event for the product, the message to theexternal agent comprising location information for the product.
 38. Amethod for remotely disabling a product in response to an event,comprising: receiving, at a device coupled to the product, a messagefrom an operations center; and responsive to receiving the message,disabling the product.
 39. The method of claim 38, wherein the productcomprises a vehicle.
 40. The method of claim 38, wherein the productcomprises one selected from the group consisting of: an appliance; acomputing device; a telecommunication device; a handheld computer; and apersonal digital assistant.
 41. The method of claim 38, furthercomprising, prior to disabling the product, outputting a warningconcerning impending disablement.
 42. The method of claim 38, furthercomprising, responsive to receiving the message, transmitting locationinformation to the operations center.
 43. The method of claim 38,further comprising: receiving a second message from the operationscenter; and responsive to receiving the second message, re-enabling theproduct.
 44. The method of claim 38, further comprising: receivingpayment information; and transmitting payment information to theoperations center.
 45. The method of claim 44, wherein receiving paymentinformation comprises receiving payment information via a credit cardreader.
 46. The method of claim 45, wherein the credit card reader iscoupled to the device.
 47. A computer program product for remotelydisabling a product in response to an event, comprising: acomputer-readable medium; and computer program code, encoded on themedium, for: detecting a trigger event; and responsive to detection ofthe trigger event, transmitting a message to a device coupled to theproduct in order to disable the product.
 48. The computer programproduct of claim 47, wherein the computer program code for disabling theproduct comprises computer program code for preventing the product fromoperating.
 49. The computer program product of claim 47, wherein thecomputer program code for disabling the product comprises computerprogram code for preventing a feature of the product from operating. 50.The computer program product of claim 47, wherein the trigger eventcomprises a payment deadline.
 51. The computer program product of claim47, wherein the transmitted message causes the device to output awarning concerning disablement.
 52. The computer program product ofclaim 47, further comprising computer program code for, responsive todetection of the trigger event, transmitting a message to an externalagent.
 53. The computer program product of claim 52, wherein theexternal agent comprises at least one selected from the group consistingof: a repossession agent; a credit issuer; a credit reporting agency; alender; a roadside assistance provider; and a seller of the product. 54.A system for remotely disabling a product in response to an event,comprising: a device coupled to the product, for disabling the productin response to receiving a message; processing logic for detecting atrigger event; and a messaging component, coupled to the processinglogic, for responsive to detection of the trigger event, transmitting amessage to the device to disable the product.
 55. The system of claim54, wherein the trigger event comprises a payment deadline.
 56. Thesystem of claim 54, wherein the messaging component transmits themessage to the device wirelessly.
 57. The system of claim 54, whereinthe messaging component transmits the message to the device via theInternet.
 58. The system of claim 54, wherein the messaging componenttransmits the message to the device via a power line.
 59. The system ofclaim 54, wherein the product comprises a vehicle.
 60. The system ofclaim 54, wherein the product comprises one selected from the groupconsisting of: an appliance; a computing device; a telecommunicationdevice; a handheld computer; and a personal digital assistant.
 61. Thesystem of claim 54, wherein the transmitted message causes the device tooutput a warning concerning disablement.
 62. The system of claim 54,wherein the messaging component further transmits a message to anexternal agent.
 63. The system of claim 62, wherein the external agentcomprises at least one selected from the group consisting of: arepossession agent; a credit issuer; a credit reporting agency; alender; a roadside assistance provider; and a seller of the product. 64.The system of claim 54, wherein the messaging component further receiveslocation information from the device.
 65. The system of claim 64,wherein the messaging component further transmits a message to anexternal agent, the message comprising the received locationinformation.
 66. The system of claim 54, further comprising: a paymentcomponent installed at the product, for receiving payment information;and a second messaging component, installed at the product, fortransmitting payment information to the processing logic.
 67. The systemof claim 66, wherein the payment component comprises a credit cardreader.